The committers listed above are authorized under a signed CLA.

• ✅ login: cmhkknight / name: cmhkknight (a775e45, e2ea949, e4cd427)
• ✅ login: XunliYang / name: XunliYang (505c181)

Hi @cmhkknight, thanks for submitting the proposal.

• Could you add issue [API Proposal] User Experience Insights  #315 to “Which issue(s) this PR fixes” so that this pull request is linked to the original issue?
• I have added this issue to the agenda for the next Backlog WG meeting (May 14); we look forward to your participation.
• The next steps would be to explain the API to the group, upload the presentation slides, and have the group review them.

Before assessing onboarding, I think we need to clarify a few points:

1. Scope and CAMARA boundary

   • Is the API intended for external application developers / API consumers, or mainly for operator customer-care / assurance systems?
   • Some use cases mention proactive customer care, technical support, single-user assurance, premium packages, or deployment recommendations. Could you clarify which parts are intended to be standardized as CAMARA northbound API behavior, and which parts are only examples of downstream business actions outside the API?

2. Overlap with existing CAMARA work

   • The proposal appears closely related to Connectivity Insights / Session Insights, especially around application KPIs, network quality scoring, thresholds, and event notifications.
   • Could you explain the exact functional delta versus Connectivity Insights and Session Insights?
   • Should this be considered as an enhancement or sub-capability under Connectivity Insights rather than as a standalone API family?

3. Consumer and data granularity

   • Is the API exposing insights for an individual device/user, a group of users, an application, a region, or an aggregated cohort?
   • The use case mentions a specific region and a group of users, but the YAML seems focused on a device-level subscription. Which model is intended?

4. Privacy, legal basis, and consent

   • The API appears to process user/device/application usage data. What legal basis is assumed?
   • Which CAMARA authorization flows are intended to be supported?
   • Can this API be used with a two-legged token, or does it always require a three-legged token when user-level data is involved?
   • What data minimization rules apply to the notification payload?

5. API model

   • Is the intended API a synchronous retrieval API, an explicit subscription API, or both?
   • If both are needed, please clarify the different use cases and payload semantics for each.

6. YAML alignment

   • The current YAML appears to contain Connectivity Insights leftovers, including scope names and event mappings.
   • The explicit subscription API seems to miss GET /subscriptions, and the POST creation response does not describe both 201 and 202 as expected by the CAMARA subscription guidelines.
   • Scope naming, event types, and subscription response data minimization should be aligned with Commonalities before further review.